Uses updated module API with global TranslationKey type that can be overridden.

This does a bunch of things because it turned out to be easier to do them all together:

• Split the translations for shared components out into the shared components package
• Likewise for the actual translated language files
• Duplicate the i18n lint job to also do the same on shared components
• Make TranslationKey a global type and override it in each project to be the keys of that project, based off each project's new en_EN.json
• Merge the two translations files back together again at build time so element web has both sets of translations at runtime
• Have shared components storybook generate the list of languages dynamically and serve each language file from the src directory so it no longer needs to depend on element web's files

What it does not do (that can be done later):

• Convert aaaaaaalllllll of element web to using _t from the context

Note that this changes the "i18n Check" workflow to split it into two so the expected checks will need changing, so this will stay pending on this PR until we update it. The two new i18n check jobs are expected fails because we are deliberately changing translated language files.

To do after merge:

• Remove the "i18n check" check from expected checks and add the two new ones
• Run localazy upload existing (with appropriate creds) to upload the shared-component non-source translations (this could also be just before merge)

Checklist

• I have read through review guidelines and CONTRIBUTING.md.
• Tests written for new code (and old code if feasible).
• New or updated public/exported symbols have accurate TSDoc documentation.
• Linter and other CI checks pass.
• I have licensed the changes to Element by completing the Contributor License Agreement (CLA)